...........

http://zhaolinjnu.blog.sohu.com/30862949.html

今天有网友在itpub上讨论data guard中主备库的启动顺序问题,针对data guard采用不同的模式,主备库的启动顺序如下:

max performance(最大性能):主库,备库的启动和关闭顺序没有先后

max availability(最大可用):要先启动备库,再启动主库,如果启动顺序相反,主库仍然能启动,但会在主库的alert.log文件中出现如下出错提示:

Tue Jan 23 09:36:26 2007alter database openTue Jan 23 09:36:26 2007LGWR: Primary database is in CLUSTER CONSISTENT modeLGWR: Primary database is in MAXIMUM AVAILABILITY modeLGWR: Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWRLNS0 started with pid=12Tue Jan 23 09:36:29 2007LGWR: Error 1034 verifying archivelog destination LOG_ARCHIVE_DEST_2LGWR: Continuing...Tue Jan 23 09:36:29 2007Errors in file /opt/oracle/admin/devdb/bdump/test_lgwr_30979.trc:ORA-01034: ORACLE not availableLGWR: Error 1034 disconnecting from destination LOG_ARCHIVE_DEST_2 standby host 'test_stb_186'Thread 1 advanced to log sequence 73Thread 1 opened at log sequence 73  Current log# 3 seq# 73 mem# 0: /forum_dbf/redo03.logSuccessful open of redo thread 1Tue Jan 23 09:36:33 2007ARC0: Evaluating archive   log 1 thread 1 sequence 72ARC0: Beginning to archive log 1 thread 1 sequence 72Creating archive destination LOG_ARCHIVE_DEST_1: '/archive_log/archive/1_72.arc'Tue Jan 23 09:36:33 2007ARC1: Evaluating archive   log 1 thread 1 sequence 72ARC1: Unable to archive log 1 thread 1 sequence 72      Log actively being archived by another processTue Jan 23 09:36:33 2007SMON: enabling cache recoveryTue Jan 23 09:36:33 2007ARC0: Completed archiving  log 1 thread 1 sequence 72Tue Jan 23 09:36:33 2007Successfully onlined Undo Tablespace 1.Tue Jan 23 09:36:33 2007SMON: enabling tx recoveryTue Jan 23 09:36:33 2007Database Characterset is US7ASCIIreplication_dependency_tracking turned off (no async multimaster replication found)Completed: alter database open

max protection(最大保护):先启动备库,再启动主库,如果顺序相反,主库实例会自动中断,数据库无法启动,并会在alert.log文件中留下如下的信息:

Tue Jan 23 09:34:00 2007alter database openTue Jan 23 09:34:00 2007LGWR: Primary database is in CLUSTER CONSISTENT modeLGWR: Primary database is in MAXIMUM PROTECTION modeLGWR: Destination LOG_ARCHIVE_DEST_1 is not serviced by LGWRLNS0 started with pid=12Tue Jan 23 09:34:03 2007LGWR: Error 1034 verifying archivelog destination LOG_ARCHIVE_DEST_2LGWR: Continuing...Tue Jan 23 09:34:03 2007Errors in file /opt/oracle/admin/devdb/bdump/test_lgwr_30812.trc:ORA-01034: ORACLE not availableLGWR: Error 1034 disconnecting from destination LOG_ARCHIVE_DEST_2 standby host 'test_stb_186'LGWR: Minimum of 1 applicable standby database requiredTue Jan 23 09:34:07 2007Errors in file /opt/oracle/admin/devdb/bdump/test_lgwr_30812.trc:ORA-16072: a minimum of one standby database destination is requiredLGWR: terminating instance due to error 16072Instance terminated by LGWR, pid = 30812

###################

http://www.itpub.net/thread-1382270-1-1.html

不取消日志应用，直接关闭dg物理备库，会不会有问题？

即直接执行：SHUTDOWN IMMEDIATE;而不执行：ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

--------

你直接关掉唯一的物理备库，是没有问题的。主库会报一些日志无法应用还是传输的错误。对主库没有影响。

这要看你主库的参数配置了,如果主库设置了最少归档成功数,备库关闭后,会导致主库出问题.另外,备库关闭了,主库在向备库归档时,发现备库关闭,会报错的.

#####################

http://space.itpub.net/12087396/viewspace-625818

1。然后给主库关闭数据库（不行把，呵呵，都进不去了怎么执行SHUTDOWN。。命令啊。没办法直接重起机器，打上了补丁，STARTUP数据库）还好比较顺利/

2。物理DG跟主库是一样的配置，所以跟主库一样进行处理，但是并没有那么顺利，机器起动不起来了，查找了许久（大概1。2小时），才发现是盘挂载不上去了。然后进行了一些修复，谢天谢地，终于顺利启动起来了。然后也打上了补丁，启动了备库，查看了ALTER日志发现MRP进程在恢复几个归档。以为就没事了。

3。第二天上班检查发现备库接收不到主库传送的归档，那个急啊，马上开始找原因了，A：查看网络（主备库互相都可以TNSPING通 log_archive_config='dg_config=(AAA,BBB)'的AAA,BBB），B：密码文件又没去动过它，应该不是这里的问题。C：开始查看参数文件，仔细的核对该有的参数都有了，也没去动过它。问题也不应该不在这啊，反反复复GOOGLE来GOOGLE去，也没搞出结果，最后看到有人说主库重起一下就好了（这个是正解），可是不敢确定啊，而且生产库岂是你随便可以起的。最后还是寻求了一些帮助进行确认，然后跟主管进行请示（夜里重起DB），终于在夜里得到了验证。心理松了好大一口气，可以睡个好觉拉/

4。我觉的应该是主库在往备库传归档的时候在一定时间或者是一定数据后如果传不过去，那主库将停止往备库传归档（因为我后来发现我手工切换主库日期，归档没传到备库，但是主库也ALTER日志也没报任何错误，备库更是没信息，可见主库已经“抛弃”备库了），而我主库当时起来的时候，备库还是挂起的状态，主库尝试往备库发归档，始终不成功。之后主库就开始“抛弃”备库了。初步我就这么解释这个原因了/

5 好了改睡觉拉/困/

#########################

http://www.eygle.com/archives/2009/11/dataguard_restart_lns.html

以下简单测试，当备库关闭后，再重启备库，主库及备库的响应过程。

在备库执行如下步骤：

Database dismounted.ORACLE instance shut down.SQL> startup mount;ORACLE instance started.

Total System Global Area 1610612736 bytesFixed Size                  2084400 bytesVariable Size             385876432 bytesDatabase Buffers         1207959552 bytesRedo Buffers               14692352 bytesDatabase mounted.SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

Database altered.

SQL> exit

当备库关闭后，主库立即检测到备库的失败：

当备库重启后：

此时备库也恢复了同步：

检查主库的LGWR日志，可以看到整个过程的后台处理：

Oracle通过数据库的Mount ID来查找目标实例，备库关闭Mount ID不存在，则错误出现。重新初始化加你LNS进程的过程如下：

清晰的了解这个过程是很有意思的，记录一下。

-The End-

###############################

http://www.itpub.net/thread-1459850-1-1.html

另外问下 到底是哪个为准？网络上有人这样确定启动关闭主从次序

第一种日常维护先后次序1、正确打开主库和备库

主库:

SQL> STARTUP MOUNT;

SQL> ALTER DATABASE ARCHIVELOG;

SQL> ALTER DATABASE OPEN;

备库:

SQL> STARTUP MOUNT;

SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE

DISCONNECT FROM SESSION;

2、正确关闭顺序

备库:

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

SQL>SHUTDOWN IMMEDIATE;

主库

SQL>SHUTDOWN IMMEDIATE;

第二种日常维护先后次序但是有一些文档说的启动应该是先备库 后从库

关闭先主库 后备库。

现在头疼 以哪一个为准？

=======

其实你只要搞清原理无所谓哪个先后的~DG很强大的

我一般都是先停掉主库archive 发送然后备库停止应用然后再关闭备库

启动的时候先启动备库在启动主库~

主要是减少无谓的报错和对DG工作原理的熟悉很重要

######################################

http://space.itpub.net/23071790/viewspace-688383

Switchover

　　一定要按照先主库，后备库的顺序执行切换命令，否则会报错，如果强行切换就变成failover了。

主库端：　　由于主库是处于open状态，有访问的，所以v$database视图中，switchover_status为sessions active。而由primary切换到standby需要数据库为open状态，因此，执行切换命令时，带上with session shutdown选项即可。　　执行完切换命令后，关闭数据库，重新启动数据库到mount状态等待日志传输，开启日志应用。　　查看alert.log可以看到主库做了哪些动作：主库断开所有session（未提交事务会回滚），切换日志并归档，传输日志到备库，给备库一个End-Of-REDO的信号，切换为standby，重新启动到mount。

SYS@dev01> select database_role,switchover_status from v$database;

DATABASE_ROLE   SWITCHOVER_STAT--------------- ---------------PRIMARY        SESSIONS ACTIVE

SYS@dev01>alter database commit to switchover to physical standby with session shutdown;

Database altered.

SYS@dev01> shutdown immediate;ORA-01507: database not mounted

ORACLE instance shut down.SYS@dev01> startup mount;ORACLE instance started.

Total System Global Area  536870912 bytesFixed Size                  2085288 bytesVariable Size             209718872 bytesDatabase Buffers          318767104 bytesRedo Buffers                6299648 bytesDatabase mounted.

SYS@dev01>alter database recover managed standby database using current logfile disconnect from session;

Database altered.

SYS@dev01> select database_role,switchover_status from v$database;

DATABASE_ROLE    SWITCHOVER_STATUS---------------- --------------------PHYSICAL STANDBYSESSIONS ACTIVE

SYS@dev01>

备库端：　　确认是否可以切换为主库，如果switchover_status为recovery needed或switchover latent，需要apply完所有归档日志才能切换。如果是sessions active则带上with session shutdown选项。apply完所有日志后，即可切换为primary，然后打开数据库。　　查看alert.log可以看到备库做了哪些动作：接收主库日志，接收到主库End-Of-REDO的信号，apply完所有日志，清空online redo log以便打开数据库，切换为primary，打开数据库。

SYS@dev01dg> select database_role,switchover_status from v$database;

DATABASE_ROLE    SWITCHOVER_STATUS---------------- --------------------PHYSICAL STANDBYSWITCHOVER LATENT

SYS@dev01dg> alter database commit to switchover to primary with session shutdown;alter database commit to switchover to primary with session shutdown*ERROR at line 1:ORA-16139: media recovery required

SYS@dev01dg>alter database recover managed standby database disconnect from session;

Database altered.

SYS@dev01dg> select database_role,switchover_status from v$database;

DATABASE_ROLE    SWITCHOVER_STATUS---------------- --------------------PHYSICAL STANDBYTO PRIMARY

SYS@dev01dg>alter database commit to switchover to primary with session shutdown;

Database altered.

SYS@dev01dg>alter database open;

Database altered.

SYS@dev01dg> select database_role,switchover_status from v$database;

DATABASE_ROLE    SWITCHOVER_STATUS---------------- --------------------PRIMARY          SESSIONS ACTIVE

SYS@dev01dg>

　　以上过过程中，由于主库断开所有session并归档，传输日志到备库，发给备库End-Of-REDO的信号，因此正常switchover时，是不会丢失数据的。　　切换完成后可以在主库归档，验证一下是否切换成功，备库是否能正常接收日志。

Failover　　当主库当掉，无法使用时，此时的切换即为failover，如果保护模式为最大性能模式，是可能丢失数据的。

备库端：　　如果是最大保护和最大可用性模式，则可以直接在备库端执行failover切换。如果是最大性能模式，为了尽可能减少数据丢失，需要检查主库是否有日志没有传输到备库，手动传输备库进行注册和恢复。注意RAC环境下，归档日志是分线程的。

SYS@dev01dg>select distinct thread#,max(sequence#) over(partition by thread#) a from v$archived_log;

   THREAD#          A---------- ----------         1        457

SYS@dev01dg>

[oracle@testdb dev01]$ scp * [email protected]:/u01/archive/dev01dg

　　注册归档日志有如下两种方法，较为简单当然是用rman了，一次注册多个。RMAN>catalog start with '/u01/archive/dev01';

SYS@dev01dg>alter database register logfile '/u01/archive/dev01dg/arch_e8fe6364_1_712757927_460.dbf';

　　apply归档日志也有两种方法。

SYS@dev01dg>alter database recover managed standby database disconnect from session;

Database altered.

SYS@dev01dg>

SYS@dev01dg>recover standby database;ORA-00279: change 2863819 generated at 03/20/2010 21:58:17 needed for thread 1ORA-00289: suggestion : /u01/archive/dev01dg/arch_e8fe6364_1_712757927_461.dbfORA-00280: change 2863819 for thread 1 is in sequence #461

Specify log: {=suggested | filename | AUTO | CANCEL}CANCELMedia recovery cancelled.SYS@dev01dg>

　　当手动apply完所有日志后，就可以failover切换到primary了。但是要注意的时，由于备库没有收到主库End-Of-REDO的信号，所以直接转换会报错，要求介质恢复。此时需要提交命令告诉备库，日志恢复已经finish了，需要进行failover切换。注意switchover时千万不要带有finish选项，否则就会变成failover了。

SYS@dev01dg> alter database commit to switchover to primary with session shutdown;alter database commit to switchover to primary with session shutdown*ERROR at line 1:ORA-16139: media recovery required

SYS@dev01dg> select database_role,switchover_status from v$database;

DATABASE_ROLE    SWITCHOVER_STATUS---------------- --------------------PHYSICAL STANDBYNOT ALLOWED

SYS@dev01dg>alter database recover managed standby databasefinish[force];

Database altered.

SYS@dev01dg> select database_role,switchover_status from v$database;

DATABASE_ROLE    SWITCHOVER_STATUS---------------- --------------------PHYSICAL STANDBYTO PRIMARY

SYS@dev01dg>alter database commit to switchover to primary with session shutdown;

Database altered.

SYS@dev01dg>alter database open;

Database altered.

SYS@dev01dg> select database_role,switchover_status from v$database;

DATABASE_ROLE    SWITCHOVER_STATUS---------------- --------------------PRIMARY          SESSIONS ACTIVE

SYS@dev01dg>

　　failover完成后，数据库其实是以resetlogs方式打开的，如果log_archive_format='arch_%d_%t_%r_%s.dbf'，可以看到归档日志的文件名会有新的resetlogs ID和sequence number，以此与原有的归档日志进行区分。

 ==================

http://blog.csdn.net/dream19881003/article/details/5514401

启动到管理模式shutdown immediatestartup nomount;alter database mount standby database;alter database recover managed standby database disconnect from session;

启动到只读的模式shutdown immediatestartup nomountalter database mount standby database;alter database database open read only;

如果在管理恢复的模式下到只读模式recover managed standby database cancel;alter database open read only;这个时候可以给数据库增加临时数据库文件(这时候热备份是没有备份过来的)

在只读模式下到管理恢复方式recover managed standby database disconnect from session;

主库和备库的切换 switchover时只能先从primary切换到standby，再从standby到primary

最简单的办法是把两个数据库的文件互换， primary到standby sqlplus /nolog < connect / as sysdba alter database commit switchover to physical standby with session shutdown; shutdown immediate; create spfile from '/../product/10.1.0/db_1/dbs/inittbdbsdby.ora'; startup nomount; alter database mount standby disconnect; exit eof lsnrctl stop lsnrctl start listenerdb

修改主机的tnsnames.ora 将主机的ip与备机的ip兑换

standby到primary more switchprimary.sh sqlplus /nolog < connect / as sysdba shutdown immediate create spfile from '/../product/10.1.0/db_1/dbs/inittdbdprim.ora'; startup exit eof lsnrctl stop listenerdb lsnrctl start 修改备库的tnsname.ora 主备库的ip互换

这样切换的要求是主备机各有两个listener，listener监听的是1521，listenerdb监听的是1522任何一个节点，在primary期间启动listener，standby期间启动listenerdb

连接data guard的客户端的tnsname配置，这样可以实现失败对换，对客户端是透明的：BOSS =(DESCRIPTION =(failover = on )(ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = 主)(PORT = 1521))(ADDRESS = (PROTOCOL = TCP)(HOST = 备)(PORT = 1521)))(CONNECT_DATA =(SID = BOSS))

备库的失败切换1，失败的切换 一般是主服务器已经不能使用，必须切换到备用的服务器，所以只操作备用服务器这一端，提供一切换脚本 more switchprimary.sh cd $HOME .bash_profile sqlplus /nolog < connect / as sysdba recover managed standby database cancel; --if standby hava standby redo logfile; --alter database recover managed standby database finish; --else alter database recover managed standby database finish skip standby logfile; --switch alter database recover managed standby database finish skip standby logfile; --open shutdown immediate create spfile from '/../product/10.1.0/db_1/dbs/inittbdbprim.ora'; startup exit eof lsnrctl stop linstenerdb lsnrctl start最后将tnsname.ora将住备库的ip对换

如果在备用端有活动的为归档的日志，或者有从主数据库拷贝过来的联机日志，可以采用如下的办法注册并恢复 alter database register logfile '/../oradata/tbdb/archive/1_87.dbf'; recover standby database;

如果有活动日志必须用 alter database recover managed standby database finish; 否则用 alter database recover managed standby database finish skip standby logfile;这样切换的备用服务器可以避免最小的数据丢失和不用retlogs，特别是对于用多个备用服务器的时候，该服务器可以马上作为主服务器而不用重新创建备用的服务器。

强行切换(激活)

这种切换是以激活备用服务器来完成的，在重新启动数据库的时候，备用激活resetlogs，这样会影响到其他的备用服务器而且必须重新再主服务器上重新构造备用服务器，一般不建议这样做 $more activeprimary.sh #!/bin/bash #switch to primary with cancel; cd $HOME . .bash_profile #cancel and startup database; sqlplus /notog < connect / as sysdba alter system arcive log current; recover managed standby database cancel; alter database activete standby database; shutdown immediate; create spfile from '/../product/10.1.0/db_1/dbs/inittbdbprim.ora'; startup exit eof lsnrctl stop listenerdb lsnrctl start

备用库的备份与恢复

1,从备用库上恢复主库的数据文件 在某些情况下，主服务器可能会损坏一到两个数据文件，如果是从主库的备份设备恢复，理论是可以的，但是可能会因为需要太多的日志，实际耗时太大，这个时候，我们可以考虑从备份的服务器上恢复该数据，因为备份的服务器和主数据库一般只是相差一个日志文件左右。1》关闭备用的数据库 recover managed standby database cancel; shutdown immediate;2》拷贝或ftp损坏的数据文件到主数据库3》在主数据库recover database datafile ‘文件名'即可

2，在备用数据库上进行备份如果想减轻主库的压力，可以在备用数据库上进行备份，因为备用数据库的特性关系，在对standby的rman备份中，不能修改rman的配置，所以没有办法自动备份控制文件。

可以采取一下方法进行备份1》备份备用数据库，可以停止恢复进程，跳转到read only的模式下，通过backup database，来备份数据库，这样的数据库处于一致的模式下

2》采用恢复目录备份standby数据库

rman target sys@dbstandbybackup database format '/../oradata/rman_backup/full_%d_%T_s%s_p%p';backup archivelog all delete input format '/../oradate/rman_backup/ctl_%d_%T_s%s_p%p';

如果采用控制文件做恢复的目录，注意alter database backup controlfile to '/../ordata/rman_backup/ctl_%d_%T_s%s_p%p';

#############################################

http://space.itpub.net/658698/viewspace-622212

第一部分 日常维护

一 正确打开主库和备库1 主库:SQL> STARTUP MOUNT;SQL> ALTER DATABASE ARCHIVELOG;SQL> ALTER DATABASE OPEN;

2 备库:SQL> STARTUP MOUNT;

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;

二 正确关闭顺序1 备库:SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;SQL>SHUTDOWN IMMEDIATE;

2 主库SQL>SHUTDOWN IMMEDIATE;

三 备库Read-Only模式打开当前主库正常OPEN状态备库处于日志传送状态.

1 在备库停止日志传送SQL> recover managed standby database cancel;

2 备库Read-only模式打开SQL> alter database open read only;

3 备库回到日志传送模式SQL> recover managed standby database disconnect from session;Media recovery complete.SQL> select status from v$instance;

STATUS------------MOUNTED

四 日志传送状态监控

1 主库察看当前日志状况SQL> select sequence#,status from v$log;

SEQUENCE# STATUS---------- ----------------51 ACTIVE52 CURRENT50 INACTIVE

2 备库察看RFS(Remote File Service)接收日志情况和MRP应用日志同步主库情况SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS2 FROM V$MANAGED_STANDBY;

PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS--------- ------------ ---------- ---------- ---------- ----------ARCH CONNECTED 0 0 0 0ARCH CONNECTED 0 0 0 0RFS RECEIVING 0 0 0 0MRP0 WAIT_FOR_LOG 1 52 0 0RFS RECEIVING 0 0 0 0可以看到备库MPR0正等待SEQUENCE#为52的redo.

3 察看备库是否和主库同步SQL> SELECT ARCHIVED_THREAD#, ARCHIVED_SEQ#, APPLIED_THREAD#, APPLIED_SEQ#2 FROM V$ARCHIVE_DEST_STATUS;

ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ#---------------- ------------- --------------- ------------0 0 0 00 0 0 00 0 0 00 0 0 00 0 0 00 0 0 00 0 0 00 0 0 00 0 0 00 0 0 01 51 1 50

可以看到备库已经将SEQUENCE#51的日志归档,已经将SEQUENCE#50的redo应用到备库.由于已经将SEQUENCE#51的日志归档,所以SEQUENCE#51以前的数据不会丢失.

4 察看备库已经归档的redoSQL> SELECT REGISTRAR, CREATOR, THREAD#, SEQUENCE#, FIRST_CHANGE#,2 NEXT_CHANGE# FROM V$ARCHIVED_LOG;

REGISTR CREATOR THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#------- ------- ---------- ---------- ------------- ------------SRMN SRMN 1 37 572907 573346RFS ARCH 1 38 573346 573538RFS ARCH 1 39 573538 573623RFS ARCH 1 40 573623 573627RFS ARCH 1 41 573627 574326RFS ARCH 1 42 574326 574480RFS ARCH 1 43 574480 590971RFS ARCH 1 44 590971 593948RFS FGRD 1 45 593948 595131RFS FGRD 1 46 595131 595471FGRD FGRD 1 46 595131 595471

REGISTR CREATOR THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#------- ------- ---------- ---------- ------------- ------------RFS ARCH 1 47 595471 595731RFS ARCH 1 48 595731 601476RFS ARCH 1 49 601476 601532RFS ARCH 1 50 601532 606932RFS ARCH 1 51 606932 607256

5 察看备库已经应用的redoSQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE#2 FROM V$LOG_HISTORY;

THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#---------- ---------- ------------- ------------1 1 366852 3682221 2 368222 3695901 3 369590 3710711 4 371071 3723881 5 372388 3767811 6 376781 3977441 7 397744 4077381 8 407738 4130351 9 413035 4130371 10 413037 4130391 11 413039 413098

THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#---------- ---------- ------------- ------------1 12 413098 4281611 13 428161 4443731 14 444373 4578151 15 457815 4630161 16 463016 4769311 17 476931 4929191 18 492919 5050861 19 505086 5206831 20 520683 5302411 21 530241 5456191 22 545619 549203

THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#---------- ---------- ------------- ------------1 23 549203 5524031 24 552403 5532301 25 553230 5533981 26 553398 5536951 27 553695 5543271 28 554327 5575691 29 557569 5612791 30 561279 5613851 31 561385 5660691 32 566069 5668251 33 566825 570683

THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#---------- ---------- ------------- ------------1 34 570683 5716271 35 571627 5718671 36 571867 5729071 37 572907 5733461 38 573346 5735381 39 573538 5736231 40 573623 5736271 41 573627 5743261 42 574326 5744801 43 574480 5909711 44 590971 593948

THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#---------- ---------- ------------- ------------1 45 593948 5951311 46 595131 5954711 47 595471 5957311 48 595731 6014761 49 601476 6015321 50 601532 6069321 51 606932 607256

可以看到备库已经将SEQUENCE#为51的归档文件应用到备库.

6 察看备库接收,应用redo数据过程.SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS;

MESSAGE--------------------------------------------------------------------------------ARC0: Archival startedARC0: Becoming the 'no FAL' ARCHARC0: Becoming the 'no SRL' ARCHARC1: Archival startedARC1: Becoming the heartbeat ARCHRedo Shipping Client Connected as PUBLIC-- Connected User is ValidRFS[1]: Assigned to RFS process 19740RFS[1]: Identified database type as 'physical standby'Primary database is in MAXIMUM PERFORMANCE modeAttempt to start background Managed Standby Recovery process

MESSAGE--------------------------------------------------------------------------------MRP0: Background Managed Standby Recovery process startedManaged Standby Recovery not using Real Time ApplyClearing online redo logfile 7 /oraguard/redo1/redo_7_1.logClearing online redo logfile 7 completeMedia Recovery Waiting for thread 1 sequence 47RFS[1]: No standby redo logfiles createdRedo Shipping Client Connected as PUBLIC-- Connected User is ValidRFS[2]: Assigned to RFS process 19746RFS[2]: Identified database type as 'physical standby'Primary database is in MAXIMUM PERFORMANCE mode

MESSAGE--------------------------------------------------------------------------------Committing creation of archivelog '/arch/1_47_552308270.arc'Media Recovery Log /arch/1_47_552308270.arcMedia Recovery Waiting for thread 1 sequence 48MRP0: Background Media Recovery cancelled with status 16037MRP0: Background Media Recovery process shutdownManaged Standby Recovery CanceledAttempt to start background Managed Standby Recovery processMRP0: Background Managed Standby Recovery process startedManaged Standby Recovery not using Real Time ApplyMedia Recovery Waiting for thread 1 sequence 48RFS[1]: No standby redo logfiles created

MESSAGE--------------------------------------------------------------------------------Committing creation of archivelog '/arch/1_48_552308270.arc'Media Recovery Log /arch/1_48_552308270.arcMedia Recovery Waiting for thread 1 sequence 49RFS[1]: No standby redo logfiles createdCommitting creation of archivelog '/arch/1_49_552308270.arc'Media Recovery Log /arch/1_49_552308270.arcMedia Recovery Waiting for thread 1 sequence 50RFS[1]: No standby redo logfiles createdCommitting creation of archivelog '/arch/1_50_552308270.arc'Media Recovery Log /arch/1_50_552308270.arcMedia Recovery Waiting for thread 1 sequence 51

MESSAGE--------------------------------------------------------------------------------RFS[1]: No standby redo logfiles createdCommitting creation of archivelog '/arch/1_51_552308270.arc'Media Recovery Log /arch/1_51_552308270.arcMedia Recovery Waiting for thread 1 sequence 52可以看到RFS接收到sequence#为51的归档文件并存至备库归档目录/arch/1_51_552308270.arc.Oracle自动应用文件/arch/1_51_552308270.arc进行备库与主库同步Oracle继续等待主库sequence 52的归档文件

五 备库归档目录维护1 找到备库归档目录SQL> show parameter log_archive_dest_1

NAME TYPE------------------------------------ --------------------------------VALUE------------------------------log_archive_dest_1 stringLOCATION=/archVALID_FOR=(ALL_LOGFILES,ALL_ROLES)DB_UNIQUE_NAME=ora2log_archive_dest_10 string

2 维护策略每周2,4,7删除已经应用的归档文件具体参见附录二

第二部分 主库正常切换

一 人工干预主库正常切换

1 在主库端检验数据库可切换状态SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;SWITCHOVER_STATUS-----------------TO STANDBY1 row selected

SWITCHOVER_STATUS:TO STANDBY表示可以正常切换.如果SWITCHOVER_STATUS的值为SESSIONS ACTIVE,表示当前有会话处于ACTIVE状态

2 开始主库正常切换如果SWITCHOVER_STATUS的值为TO STANDBY 则:SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY;如果SWITCHOVER_STATUS的值为SESSIONS ACTIVE 则:SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;成功运行这个命令后，主库被修改为备库

3 重启先前的主库SQL> SHUTDOWN IMMEDIATE;SQL> STARTUP MOUNT;

4 在备库验证可切换状态SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;SWITCHOVER_STATUS-----------------TO_PRIMARY1 row selected

5 将目标备库转换为主库如果SWITCHOVER_STATUS的值为TO STANDBY 则:SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;如果SWITCHOVER_STATUS的值为SESSIONS ACTIVE 则:SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;成功运行这个命令后，备库被修改为主库

6 重启目标备库SQL> SHUTDOWN IMMEDIATE;SQL> STARTUP;

7 先前主库启动日志传送进程SQL> alter database recover managed standby database disconnect;

总结: 这样主库的一次正常切换完成.切换后的状态,原先的主库变为备库,原先的备库变为主库.

二 通过运行脚本实现主库正常切换

1 主库切换为备库在主库上运行脚本/admin/dataGuard/switchover/primary_to_standby.sh

2 备库切换为主库在备库上运行脚本/admin/dataGuard/switchover/standby_to_primary.sh

脚本1成功运行后,再运行脚本2,不能同时运行两个脚本.经过这次切换后原来的主库变为备库,原先的备库变为主数据并且OPEN对应用提供服务.

3 复原最初状态在原备库上运行脚本/admin/dataGuard/switchover/primary_to_standby.sh成功完成后在原主库上运行脚本/admin/dataGuard/switchover/standby_to_primary.sh

第三部分 主库灾难切换一 人工干预主库灾难切换二 通过运行脚本实现主库灾难切换

SQL>alter database recover managed standby database cancel;SQL>shutdown immediateSQL>startup mountSQL>ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;SQL>alter database recover managed standby database finish;-- switchSQL>alter database commit to switchover to primary with session shutdown;-- openSQL>shutdown immediateSQL>startup

附:一 有选择察看redo传送与应用情况select message from v$dataguard_statuswhere message_num>&message_num;

二 备库归档目录维护脚本在crontab 中定制每日执行removeCommand.sh即可。流程:每日11:50PM执行removeCommand.sh假设今日2005-04-05 则删除04-04和04-03两日已应用归档日志.保留今日已应用归档日志

[oracle@db_gurid admin]$ crontab -l50 23 * * * sh /oraguard/admin/removeCommand.sh>>removeArch.log##################

[oracle@db_gurid admin]$ cat removeCommand.sh#!/bin/shexport ORACLE_BASE=/ora10g/appexport ORACLE_HOME=$ORACLE_BASE/product/10.1.0/db_1export ORACLE_SID=ora2

cd /oraguard/admin$ORACLE_HOME/bin/sqlplus /nologremoveArch2.log##################

[oracle@db_gurid admin]$ cat removeArch.sqlset feed offset heading offset echo offspool removeArch.shselect 'rm '||name from v$archived_log where applied='YES' and completion_time>trunc(sysdate-3) and completion_time ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY；

　　对于逻辑备数据库，指定下面的 SQL 语句：

　　SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NODELAY；

　　这些命令导致日志应用在时间间隔过期之前，立即开始应用归档重做日志文件到备数据库。

　　使用Flashback 数据库作为设置时间延迟的另一选择

　　作为设置应用延迟的另一选择，你能使用Flashback 数据库来从损坏或错误数据的应用中恢复到备数据库。Flashback 数据库能快速、简单地闪回备数据库到一个任意的时间点。

　　三、应用重做数据到物理备数据库

　　默认地，重做数据从归档重做日志文件应用。当执行重做应用时，物理备数据库能使用实时应用特性来从正在被RFS 进程写的备重做日志文件直接应用重做。注意当物理备数据库以只读模式打开时日志应用服务不能应用重做数据。

　　开始重做应用

　　要在物理备数据库上开始日志应用服务，确保物理备数据库是启动并安装的，然后使用SQL:ALTER DATABASE RECOVER MANAGED STANDBY DATABASE 语句来开始重做应用。

　　你能指定重做应用作为前台会话或后台进程运行，并允许它实时应用。

　　要在前台开始重做应用，执行下面的 SQL 语句：

　　SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE；

　　如果你开始一个前台会话，控制不会返回到命令提示符，直到恢复被其它会话取消了。??  要在后台开始重做应用，在 SQL 语句中包括DISCONNECT 关键词。例如：

　　SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT；

　　这条语句开始了一个分离的服务进程并立即返回控制到用户。当管理恢复进程在后台执行恢复，执行RECOVER 语句的前台进程能继续执行其它任务。这不会断开当前的SQL 会话。

　　要开始实时应用，在 SQL 语句上包含USING CURRENT LOGFILE 字句。例如：

　　SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE；

　　停止重做应用

　　要停止重做应用，在其它窗口执行下面的 SQL 语句：

　　SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL；

　　四、应用重做数据到逻辑备数据库

　　SQL 应用从归档重做日志或备重做日志转换数据到SQL 语句，然后在逻辑备数据库上执行这些SQL 语句。因为逻辑备数据库保持打开，维护的表能同时用于其它任务，如报表、总结、和查询。

　　开始SQL 应用

　　要开始 SQL 应用，启动逻辑备数据库并执行下面语句：

　　SQL> ALTER DATABASE START LOGICAL STANDBY APPLY;

　　在逻辑备数据库上停止SQL应用

　　要停止SQL 应用，在逻辑备数据库上执行下面语句：

　　SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

　　当你执行该语句，SQL 应用等待直到它提交了所有在应该过程中完成的事务。这样，该命令可能不能立即停止SQL 应用进程。如果你想立即停止 SQL 应用，执行下面语句：

　　SQL> ALTER DATABASE ABORT LOGICAL STANDBY APPLY;